home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / oim / oim-minutes-90dec.txt < prev    next >
Text File  |  1993-02-17  |  6KB  |  155 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Brian Handspicker/Digital
  8.  
  9. OIM Minutes
  10.  
  11. Agenda
  12.  
  13.  
  14.    o RFC 1189 CMIP and CMOT Implementors Agreements for the Internet
  15.    o OIM-MIB-II
  16.    o General OSI MIB Extensions
  17.    o Interoperability Testing
  18.  
  19.  
  20. RFC 1189 CMIP/CMOT
  21.  
  22. RFC 1189 has been published as a Proposed Standard.  Pending major
  23. objections on the mailing list, we agreed to remove the word
  24. ``substrings'' from the 1st bullet in section 4.3.  This would remove
  25. the explicit exemption for support of substrings in filter expressions.
  26. In addition, the editor agree to clarify the specific 1990 version of
  27. ISO CMIS/P to be used, with the intent to use the final 1990 version.
  28. Finally, we discussed at length the 3 different potential protocols
  29. supported by 1189.  1189 specifies support of either a CMIP application
  30. layer over Lightweight Presentation Process over TCP/IP or, a CMIP
  31. application layer over an OSI upper layer stack.  The OSI upper layers
  32. could in turn be based on either a full set of OSI lower layers or on
  33. ISO Transport over TCP/IP using agreements specified in RFC 1006.
  34.  
  35. Clearly, a version of CMIP over a full OSI stack will be important for
  36. future OSI-based Internet backbone and sub-nets.  Some version of CMIP
  37. should also be defined for IP-based Internet backbone and sub-nets.
  38. Since they provide similar functionality, CMOT based on LPP and a CMIP
  39. based on 1006 could be considered redundant.  At the Tallahassee IETF
  40. meeting, it was recommended that all future protocols which require OSI
  41. upper layer functionality over IP-based protocols make use of RFC 1006.
  42. As a result, a couple of suggestions have been made that the
  43. specification for CMIP over LPP be removed from RFC 1189, and the
  44. potential use of RFC 1006 be clarified in the current text.
  45. Editorially, this is a minor change involving the removal of the one
  46. page which discusses how to layer CMIP over LPP and deletion of the
  47. phrase ``CMOT and'' from every instance of ``CMOT and CMIP''. Otherwise
  48. the technical implementors' agreements in RFC 1189 remain unchanged.
  49. Most known implementations of CMOT have been based on the LPP
  50. implementation distributed with ISODE. To convert these CMOT
  51. implementations to CMIP 1006 implementation requires little more than a
  52.  
  53.                                    1
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60. one line change to a makefile to reference the full ISODE library
  61. instead of the LPP library.  While the wireline difference is
  62. significant, ISODE and RFC 1006 has been well exercised over the last 2
  63. years.  And, the CMIP application layer agreements specific in RFC 1189
  64. remain unchanged.  Thus, the suggestion to remove the specification of
  65. CMOT in favor of an RFC 1006-based CMIP is a relatively minor technical
  66. change to the existing RFC. It was pointed out that this change would
  67. align RFC 1189 with existing GOSIP and DOD requirements for OSI
  68. management.
  69.  
  70. OIM-MIB-II
  71.  
  72. OIM-MIB-II was announced as being considered by the IESG as a proposed
  73. standard.  No objections or major corrections were offered by the
  74. meeting participants.
  75.  
  76. General OSI MIB Extensions
  77. Once again, we have wrestled with the problem of mapping MIB definitions
  78. that follow the IETF SMI into a form supported by the ISO SMI. The IETF
  79. SMI was based on a very early draft of the ISO SMI. The ISO SMI
  80. continued to evolve as early problems were resolved.  The IETF SMI has
  81. not kept pace.  The ISO SMI is now stable and required by most OSI-based
  82. management systems.  Unfortunately most of the MIBs being defined within
  83. the IETF are only satsifying the requirements of the IETF SMI, not
  84. taking into account the minor additional requirements for OSI
  85. management.  This requires additional work to map these IETF SMI-based
  86. MIBs into ISO SMI. This is what the OIM-MIB-II document does for MIB-II.
  87. Unfortunately, the OIM Working Group cannot hope to keep up with all of
  88. the MIB work currently being progressed within the IETF and generate MIB
  89. extensions and mappings for each new MIB. In addition, some of the MIB
  90. Working Groups are facing the reverse problem - trying to map ISO SMI
  91. defined MIBs (e.g., FDDI) into the IETF SMI. The most reasonable
  92. solution to this problem would be to put differences about protocols
  93. (SNMP and CMOT) behind us and encourage the individual MIB Working
  94. Groups to develop MIB definitions that support both the IETF SMI and ISO
  95. SMI. This would ensure that all MIB definitions - which really just
  96. defined manageable resources, without any dependence on management
  97. protocols - were aligned across whatever management protocol or
  98. management system was used by an administrator for managing an
  99. environment.
  100.  
  101. If we do not resolve this issue, we run the risk of having different
  102. management definitions (MIBs) for the same resources.  This would waste
  103. resources both within the IETF as well as within every vendor and many
  104. customers.  We agreed to raise this to the IESG for reconsideration.
  105.  
  106. Interoperability Testing
  107.  
  108.  
  109.                                    2
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116. We discussed future interoperability testing, and an open invitation was
  117. made by Brian Handspicker to coordinate another round of
  118. interoperability testing.  Any vendors interested in testing RFC 1189
  119. CMOT or CMIP are invited to send mail to bd@vines.dec.enet.com.
  120.  
  121. Attendees
  122.  
  123. Vikas Aggarwal           vikas@JVNC.net
  124. Steve Alexander          stevea@i88.isc.com
  125. Jack Brown               jbrown@huachuca-emh8.army.mil
  126. Gregory Bruell           gob@shiva.com
  127. Jeffrey Case             case@cs.utk.edu
  128. Curtis Cox               zk0001@nhis.navy.mil
  129. Tony Hain                alh@eagle.es.net
  130. Brian Handspicker        bd@vines.enet.dec.com
  131. Holly Knight             holly@apple.com
  132. Lee Labarre
  133. Nik Langrind             nik@shiva.com
  134. Walter Lazear            lazear@gateway.mitre.org
  135. John Lunny               jlunny@twg.com
  136. Lynn Monsanto            monsanto@sun.com
  137. Bahaa Moukadam
  138. Oscar Newkerk            newkerk@decwet.enet.dec.com
  139. Fred Ostapik             fred@nisc.sri.com
  140. Mark Seger               seger@asds.enet.dec.com
  141. Theresa Senn             tcs@cray.com
  142. Daisy Shen               daisy@ibm.com
  143. Daisy Shen               daisy@ibm.com
  144. Mark Sleeper             mws@sparta.com
  145. Sudhanshu Verma          verma@hpindbu.cup.hp.com
  146. A. Lee Wade              wade@discovery.arc.nasa.gov
  147. David Waitzman           djw@bbn.com
  148. Linda Winkler            b32357@anlvm.ctd.anl.gov
  149. Fei Xu                   fei@tdd.sj.nec.com
  150. Jeff Young               jsy@cray.com
  151.  
  152.  
  153.  
  154.                                    3
  155.